pp108 : Case Instance Specific Properties

Case Instance Specific Properties
This topic describes the XML structure of a Case instance.

When a Case model is instantiated, a property is instantiated in the Message Map to provide instance-specific properties. These properties are collectively known as instance properties. They are used to retrieve information about the Case instances at the runtime and can be used in Case definitions.

XML Structure of Instance-Specific Properties

The XML structure of instance-specific properties are as follows:

<instanceProperties debugMode="true">
    <source type="CASE">00215A63-1B7C-11E2-EAC6-E35CBC02BFED</source>
    <currentstate id="RootCaseModelState">Default State</currentstate>
    <identifier>00215A63-1B7C-11E2-EAC6-E32BDCFF3FED</identifier>
    <name>TestCaseModel</name>
    <modelid>{5D8D56E3-523A-47E1-9118-F24520F58201}</modelid>
    <modelrevision>00215A63-1B7C-11E2-EAC6-E32BDCFE5FED</modelrevision>
    <currentuser>cn=jdoe,cn=organizational users,o=system,cn=cordys,o=vanenburg.com</currentuser>
    <lastmodified>1357280545980</lastmodified>
    <space>organization</space>
    <instantiationuser>cn=JDoe,cn=organizational users,o=system,cn=cordys,o=vanenburg.com</instantiationuser>
    <startTime>1267526084395</startTime>
    <organization>o=system,cn=cordys,o=vanenburg.com</organization>
    <priority>3</priority>
    <rootinstance>00215A63-1B7C-11E2-EAC6-E32BDCFF3FED</rootinstance>
    <rootinstancetype>CASE</rootinstancetype>
    <activityinfo>
        <PriorActivityInstanceDetails>
            <Name>TestSubCaseModel</Name>
            <Id>00215A63-1B7C-11E2-F840-C8A87E477F09</Id>
            <InstanceId>00215A63-1B7C-11E2-F859-F4830FA9BFBF</InstanceId>
            <Type>CASETASK</Type>
            <Status>COMPLETED</Status>
        </PriorActivityInstanceDetails>
    </activityinfo>
    <stateinfo>
       <PriorStateInstances>
		<State>
			<Name>Validation</Name>
			<Id>001CC435-DD29-11E3-EB97-B174AB7D9289</Id>
			<Parent>001CC435-DD29-11E3-EBCD-55E343EE1024</Parent>
		</State>
		<State>
			<Name>Registration</Name>
			<Id>001CC435-DD29-11E3-EBCD-55E343EE1024</Id>
			<Parent>RootCaseModelState</Parent>
		</State>
	</PriorStateInstances>
	<ActiveStates>
		<State>
			<Name>Confirm</Name>
			<Id>001CC435-DD29-11E3-EBCD-5A886CDAF024</Id>
			<Parent>001CC435-DD29-11E3-EBCD-5A886CE07024</Parent>
		</State>
		<State>
			<Name>Approval</Name>
			<Id>001CC435-DD29-11E3-EBCD-5A886CE07024</Id>
			<Parent>RootCaseModelState</Parent>
		</State>
	</ActiveStates>
    </stateinfo>
</instanceProperties>

Elements in the XML Structure of Instance-Specific Properties

The following table describes the elements in the XML structure of instance-specific properties:

Element

Description

source

Parent process instance ID from which the current Case instance is instantiated. This information helps in scenarios where a Case instance requires to be aware of the parent process that instantiated it.

type

Application type that created the instance. The possible values are:

  • Web service - The default value when a Case instance is created using the CreateCase API. You can also customize the value as a part of the parameter source in the CreateCase API.
  • CASE - The value when a Case instance is triggered from another Case instance
  • PROCESS - The value when a Case instance is triggered from another BPM instance

currentstate

State of the Case instance

Note: This property is currently deprecated. Property stateinfo/ActiveStates/State/Name  can be used to get current state of the Case Instance.

id

Unique identifier of the current state of the Case instance

identifier

Unique identifier of the Case instance

name

Name of the Case

modelid

Unique identifier of the Case model

modelrevision

Custom Case instantiation type. It can be used by applications to specify their identity for better Case monitoring and data filtering.

currentuser

LDAP DN of the user or role that last triggered the Case instance.
Note: Initially, the DN will be the same as the value in the instantiationuser element. However, if the Case instance is triggered again by an intermediate user or role, that user or role will be the owner for further operations in the process. For example, if a Case instance sends a message to a participant and is waiting for a response, the participant in turn sends back a response that triggers the same Case instance. The owner for all the future operations with the Case instance is the participant whose response triggered the Case instance.

lastmodified

The time when the Case instance was last modified. The format of lastmodified is usually in 13 digits, where the last three digits are milliseconds. For example, if the startTime is '1267526084498', '498' indicates milliseconds and need not be converted to a valid Process Platform or UTC format.

space

Place from which the Case instances are executed and displayed in the Case Instance Manager

instantiationuser

LDAP DN of the user or role that instantiated the Case instance

startTime

Time when the Case instance was instantiated. The format of startTime is usually in 13 digits, where the last three digits are milliseconds. For example, if the startTime is '1267526084395', '395' indicates milliseconds and need not be converted to a valid Process Platform or UTC format.

organization

DN of the organization in which the Case instance is created

priority

Execution priority of the Case, where the priority ranges from 1 to 5; 1 corresponding to low and 5 corresponding to high.

rootinstancetype

Source type of the root of the instance. It can be a Process or Case model.

rootinstance

Displays the Process instance ID if the rootinstancetype is PROCESS and displays the Case instance ID if the rootinstancetype is CASE.
PriorActivityInstanceDetails

In a Case model, you can now map the previous activity details as a part of the pre-assignment of activity. This option is available for the activities that are connected through Automatic, Manual, or Intermediate followup modes and if both the previous and current activities are in the same 'State'. This information is completely transient, and it will not get stored. This information is only available in the message map. The following are the details:

  • Name: Description of the previous activity
  • Id: Unique identifier of the previous activity as available in the design time
  • InstanceId: Unique identifier of the previous activity instance as available in the runtime.
  • Type: Type of the previous activity. It contains one of the following values:
    • HUMANTASK - If the activity is associated to a User Interface
    • BPMTASK - If the activity is associated to a BPM model
    • CASETASK - If the activity is associated to a Case model
  • Status: Status of the previous activity. The possible values are:
      • COMPLETED - When the previous activity has already been completed
      • SUSPENDED - When the current activity is triggered as a part of the intermediate followup of the previous activity

PriorStateInstances

Details of the previous active states. When a transition is considered from one state to another state, the current state and its parent states are considered as previous states. This information can be used in scenarios where an application wants to traverse back to the previous states from the current active state.

A state in which the Case instance exists presently is considered as active.

Note: PriorStateInstances stores the details of all the completed states in the most recent state transition. For a single transition, the state that exits first will be added to the first child of the PriorStateInstances node followed by the next state and so on. When a state has sub-states, all the sub-states are exited before the parent state exits. The parent state information is always the last state in the PriorStateInstances node.

Consider the following scenarios:

  • ParentState1 has two nested sub-states: SubState1 followed by SubState2
    When ParentState1 exits, both the sub-states will exit before the ParentState1; that is, SubState1 will exit first, followed by SubState2 and ParentState1. The same order will be followed while adding the details in the PriorStateInstances node.
  • ParentState1 has SubState1, and SubState1 in turn has a nested SubState2.
    When ParentState1 exits, SubState2 will exit first, followed by SubState1 and ParentState1. The same order will be followed while adding the details in the PriorStateInstances node.

The following are the details available in PriorStateInstances:

  1. State/Name: Name of the state that was previously active
  2. State/Id: Unique identifier of the related state as available in the design time. It can be used in scenarios where applications want to drill-down to the details of a particular state.
  3. State/Parent: Unique identifier of the parent of the state as available in the design time. It can be used in scenarios where hierarchy of the state is required.
ActiveStates

Details of current active states.

A state in which the Case instance exists presently is considered as active.

The following are the details available in ActiveStates:

  1. State/Name: Name of the state that is active
  2. State/Id: Unique identifier of the related state as available in the design time. It can be used in scenarios where applications want to drill-down to the details of a particular state.
  3. State/Parent: Unique identifier of the parent of the state as available in the design time. It can be used in scenarios where hierarchy of the state is required.